Software development environments are computing environments that support both (i) a production (or “official”) platform, and also (ii) informal workspaces that are derived from the official and which developers use on their own private computing devices to develop new source code and/or diagnostics and/or bugfixes. Typically, the production platform comprises an official software base (including, e.g., source code, files, configuration parameters, etc.) for building executable code and/or associated binary files (the “executable”). The executable(s) may be provided to customers as an “official release.” The official software base (or “build”) may be stored in a build-volume on a storage device such as a storage array. A so-called build server may manage the source code in the software base and may also generate the official release from an official software base.
Workspaces are private developer copies that may be derived from an official software base. Typically, a developer obtains a copy of the official software base to use as a workspace on her/his own computing device. The workspace may be tested and if the changes are deemed of appropriate quality, the workspace may be submitted for integration, so that the changes developed by the developer may be incorporated into the official base.
The process for obtaining copies of the official software base and generating workspaces for a large number of developers may consume huge amounts of storage. Because each developer may be working with one or more workspaces at any given time (e.g., on several different releases and/or features) and each workspace may comprise a copy of an official software base, which may be very large to begin with, the storage consumed by so many copies could rapidly exceed the storage capacity available in the development environment. An exemplary prior-art approach to providing workspaces and the necessary storage therefor is presented in FIG. 1. This approach and others like it have disadvantages that make them unsuitable for certain large software development environments that operate with a large software base and have many developers vying for workspaces.
FIG. 1 depicts a typical prior-art approach to providing connectivity and storage for workspaces in a software development environment 100. FIG. 1 depicts storage array 104, comprising a build-volume BV1 and n array-created hardware snapshots S1-Sn; build server 106, and n user computing devices D1-Dn (108). Logical communication pathways between the components are depicted by the dotted bi-directional arrows labeled 150, and 151-1, . . . , 151-n. 
Storage array 104 may be a high-capacity mass storage device that is well known in the art. Storage array 104 also includes array-based hardware snapshot capability, which is also well-known in the art and is discussed in more detail in regard to array-created hardware snapshots S1-Sn. Storage array 104 may comprise one or more data storage technologies, and may be any kind of block storage array, e.g., storage-area network (SAN) array technologies. An example of storage array 104 may be a Dell EqualLogic™ array from Dell, Inc. of Round Rock, Tex., USA. Storage array 104 may comprise several volumes, including build-volume BV1 (element 110) and n array-created hardware snapshots S1-Sn (elements 111-1, . . . . , 111-n).
Build server 106 is a computing device, well known in the art, which is generally directed at managing source code, which may include compiling the source code in a software base and generating executables. In the present example, build server 106 executes a Microsoft Windows® operating system (e.g., from Microsoft Corp., Redmond, Wash., USA), and therefore may be referred to as a Windows-based computing device. Software development environment 100 as a whole may be referred to as a Windows-based development environment, because the build server 106 and developers' machines 108 are Windows-based computing devices. Build server 106 may perform one or more of the following functions in software development environment 100:                Establish communications with storage array 104, e.g., via logical communication path 150.        Request storage array 104 to create build-volume BV1, e.g., sized at 200 GB to accommodate a software base.        Map build-volume BV1 to build server 106.        Mount build-volume BV1 to build server 106 as a logical volume number.        Format build-volume BV1 according to a Windows-based file system, e.g., New Technology File system (NTFS) from Microsoft Corp., which executes on build server 106.        Use build-volume BV1 as a Windows-based (e.g., NTFS) volume for storing a software base or build, e.g., build 16.        
User computer devices D1-Dn (elements 108-1, . . . , 108-n) are computing devices assigned to individual developers, and may be referred to herein as “developer machines.” In the present example, each developer machine D (component 108) executes a Microsoft Windows operating system, and may be referred to as a Windows-based computing device or Windows-based developer machine. A developer machine 108 operating in software development environment 100 may perform one or more of the following functions:                Establish communications with storage array 104, e.g., via a logical communication path 151.        Request a snapshot of build-volume BV1, e.g., requesting storage array 104 to generate a hardware snapshot S of BV1 such as array-created snapshot S1.        Map the snapshot S to developer machine D.        Mount snapshot S to developer machine D.        Use snapshot S as an NTFS volume, comprising a copy of the software base, for the developer's workspace.        
Array-created build-volume BV1 (element 110) is a volume created in storage array 104 that has been designated to store a software base. Build-volume BV1 is accessible to build server 106, as indicated by the solid arrow 150. In the present example, build-volume BV1 is sized at 200 GB and is formatted for NTFS (New Technology File system from Microsoft Corp.), which is a file system (or “filesystem”) that is based on and compatible with the Microsoft Windows@operating system. Thus, NTFS may be said to be a Windows-based file system. Build-volume BV1 may be of any size and may be formatted for any Windows-based file system, not necessarily NTFS.
Array-created hardware snapshots S1-Sn (elements 111-1, . . . , 111-n) are so-called “hardware snapshots” or “hardware-based snapshots,” which are created by storage array 104. A snapshot is a point-in-time copy of a defined collection of data that acts as a source. A snapshot may be thought of as an instant image of source data at a given point in time (e.g., a build-volume, such as build-volume BV1, which may comprise a software base). Thus, build-volume BV1 may be thought of as the source for snapshots S1-Sn. An array-created snapshot is generated by storage array 104 in a self-contained fashion, substantially independently, using hardware, firmware and/or software residing/executing on the storage array itself. For instance, storage array 104 may be capable of performing snapshot operations upon request from another component, generally without intervention or oversight from other components, thus off-loading other components from processing needed for snapshot creation and management.
In the present example, a snapshot S (e.g., S1, . . . , Sn) is generated by storage array 104 from a source which is build-volume BV1. The snapshot S may be created in response to a command/request issued by build server 106, a developer's machine 108, or by another component (not shown here). The array-created hardware snapshot S is an exact copy of the source volume BV1.
Logical communication pathways 150 and 151 (e.g., 151-1, . . . , 151-n) may be supported by any suitable underlying physical communications infrastructure. For example, logical communication pathways 150 and 151 may include one or more networks or other connection types including one or more of the following: the Internet, a wide area network (WAN), a local area network (LAN), a Small Computer System Interface (SCSI) connection, a virtual private network (VPN), and/or other appropriate computer or telecommunications networks, combinations of the same or the like.
The present figure illustrates only a handful of snapshots S and only two developer machines D in software development environment 100. However, the number of development machines may reach well into the hundreds, each development machine D requiring its own dedicated one or more snapshots S in storage array 104. Only one build-volume BV1 is illustrated here, but a software development environment may operate with several official software bases corresponding to different releases and/or service packs, each one causing potentially hundreds of corresponding snapshots S to be created for respective developers' workspaces. The result is that the physical storage capacity of storage array 104 may be quickly exhausted and necessitate the purchase of another storage array, which is a major expense and a considerable increase in the complexity of the software development environment. This represents a substantial disadvantage of the prior-art approach depicted in FIG. 1. It would be desirable to devise a more efficient, yet robust, way to avoid or at least to slow down the growth in storage space used for providing developer workspaces.